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An efficient and flexible engine for computing fixed-points is critical for many practical applica- 
tions. In this paper, first, we present a goal-directed fixed-point computation strategy for the 
logic programming paradigm. Our strategy adopts tabled resolution (or memoized resolution) to 
mimic efficient semi-naive bottom-up computation. Its main idea is to dynamically identify and 
record those clauses that will lead to recursive variant calls, and then repetitively apply those 
alternatives incrementally until the fixed-point is reached. Second, we consider those situations 
in which a fixed-point contains a large number or even an infinite number of solutions. In these 
CJ1SGS, SL fixed-point computation engine may not be efficient enough or feasible at all. We present 
a mode-declaration scheme which provides the capabilities to reduce a fixed-point from a large 
set of solutions to a preferred smaller one, or from an infinite set that is infeasible to compute to 
a finite one. The mode declaration scheme can be characterized as a meta-level operation over 
the original fixed-point. We show the correctness of the mode declaration scheme. Third, the 
mode-declaration scheme provides a new declarative method for dynamic programming, which is 
typically used for solving optimization problems. Using the mode declaration scheme, there is no 
need to define the value of an optimal solution recursively, instead, defining a general solution 
suffices. The optimal value as well as its corresponding concrete solution can be derived implicitly 
and automatically using a mode-directed fixed-point computation engine. Finally, this fixed-point 
computation engine has been successfully implemented in a commercial Prolog system. Experi- 
mental results are shown to indicate that adopting the mode declaration scheme improves both 
time and space performances in solving dynamic programming problems. 
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1. INTRODUCTION 

Due to their highly declarative nature and efficiency, Tabled Logic Programming 
(TLP) systems [Chen and Warren 1996; Zhou et al. 2000; Guo and Gupta 2001; 
Rocha et al. 2001] have been put to many innovative uses, such as model checking 
[Ramakrishnan et al. 1997] and non-monotonic reasoning [Swift 1999], A tabled 
logic programming system can be thought of as an engine for efficiently comput- 
ing fixed-points, which is critical for many practical applications. A TLP system 
is essential for extending traditional LP system (e.g., Prolog) with tabled resolu- 
tion (or memoized resolution). The main advantages of tabled resolution are that 
it terminates more often by computing fixed-points, avoids redundant computa- 
tion by memoing the computed answers, and keeps the declarative and procedural 
semantics of pure logic programs with bounded-size terms consistent. 

The main idea of tabled resolution is never to compute the same call twice. 
Answers to certain calls are recorded in a global memo table (heretofore referred 
to as a table), so that whenever the same call is encountered later, the tabled 
answers are retrieved and used instead of being recomputed. This avoidance of 
recomputation not only gains better efficiency, more importantly, it also gets rid of 
many infinite loops, which often occur due to static computation strategies (e.g., 
SLD resolution [Lloyd 1987]) adopted in traditional logic programming systems. 

In this paper, we present a novel tabled resolution strategy for computing fixed- 
points in the logic programming paradigm. We focus on definite logic programs. 
The strategy applies a memoized recursive algorithm to mimic efficient semi-naive 
bottom-up computation. Its main idea is to dynamically identify and record those 
clauses that will lead to recursive variant calls 1 , and then repetitively apply these 
alternatives incrementally until the fixed-point is reached. Our tabled resolution 
scheme allows query evaluation to be performed with a single computation tree 
similar to traditional SLD resolution. As a result, this novel tabled resolution 
scheme can be easily incorporated into an existing pure Prolog system without 
involving any major changes to it. 

Example 1. Consider the following two programs defining the reachability re- 
lation. The predicate reach(X,Y) in the program (a) checks whether a node Y is 
reachable from node X, while the predicate reach (X,Y,E) in the program (b) per- 
forms the same task but additionally returns the path from X toY as an explanation 
(i.e., why Y is reachable from X). 

:- table reach/2. 

reach(X,Y) :- reach(X,Z), arc(Z,Y). 
reach(X,Y) :- arc(X,Y) . 
arc(a,b). arc(a,c). arc(b,a). 
: - reach(a,X) . 

(a) A Fixed-Point with Finite Number of Solutions 



1 We say two Prolog calls Ci and C*2 arc variant if there exist substitutions <j> and a such that 
C\ = C2<f> and C2 = C\cr. 
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:- table reach/3. 
reach(X,Y,E) :- 

reach(X,Z,El) , arc(Z,Y,E2), append (El, E2, E) . 
reach(X,Y,E) : - arc (X, Y,E) . 

arc(a,b, [(a,b)] ) . arc(a,c, [(a,c)] ) . arc(b,a, [(b,a)] ) . 
: - reach(a,X,P) . 

(b) A Fixed-Point with Infinite Number of Solutions 

The program in example 1(a), for checking the existence of reachability, does not 
work properly in a traditional Prolog system. With the declaration of a tabled pred- 
icate reach/2 in a tabled Prolog system, it can successfully find the complete set 
of solutions due to the fixed-point computation strategy. However, there are many 
situations in which a fixed-point contains a large number or even infinite number 
of solutions, which in turn affects the efficiency or completion of the computation. 

Consider the reachability program shown in example 1(b), where append/3 is a 
standard predicate used to append one list to another. An extra argument is added 
to the predicate reach/3 to collect the path that connects its first argument to its 
second argument. However, this extra argument results in the fixed-point of the 
computation becoming infinite. Tabled resolution now becomes nonterminating, 
since now there are infinite number of paths from a to any node due to the cycle 
between a and b. Similar problems on evidence construction have been studied on 
justification in [Roychoudhury et al. 2000; Pemmasani et al. 2004]. One reasonable 
solution is presented in [Pemmasani et al. 2004] by asserting the first evidence 
into a dynamic database for each tabled answer. However, the evidence has to be 
organized as segments indexed by each tabled answer. That is, an extra procedure 
is required to construct the full evidence. 

To avoid problems of inefficiency or nontermination, due to the fixed-point con- 
taining a large number or an infinite number of solutions respectively, it is often 
necessary to change the original problem so that there is only a small finite-sized 
solution set. For the reachability example, it is actually enough to find a single 
simple path to show the evidence of reachability However, generally, it is not only 
difficult to alter the predicate definition of reach/3 to avoid nontermination in or- 
der to have a single simple path for each pair of reachable nodes, it also sacrifices 
the clarity of the original relation. In these cases, a fixed-point computation engine 
may not be efficient enough or feasible at all. We present a declarative method to 
get around this problem by introducing a new mode declaration scheme [Guo and 
Gupta 2004]. 

In this paper, we present a mode-declaration scheme [Guo and Gupta 2004] in 
a tabled Prolog paradigm which provides the user the capability to reduce the 
fixed-point of a definite logic program from a large- or infinite-sized solution set 
to a preferred finite-sized one. The method introduces a new mode declaration for 
tabled predicates. The mode declaration classifies arguments of a tabled predicate 
as indexed or non-indexed. Each non-indexed argument can be thought of as a 
function value uniquely determined by the indexed arguments. The tabled Prolog 
system is optimized to perform variant checking based only on the indexed argu- 
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ments during the computation of fixed-points. The mode declaration can further 
extend one of the non-indexed arguments to be an aggregated value, e.g., the min- 
imum function, so that the global table will record answers with the value of that 
argument appropriately aggregated. Thus, in the case of the minimum function, 
a tabled answer can be dynamically replaced by a new one with a smaller value 
during the computation. This new declaration for tabled predicates and modified 
procedure for variant checking make it easier for the meta-level manipulation during 
computation of fixed-points. 

Semantically, the mode declaration scheme can be characterized as a meta-level 
operation over the fixed-point of the original program. The semantics of a tabled 
Prolog program is formalized based on the Herbrand model [van Emden and Kowal- 
ski 1976; Lloyd 1987] and fixed-point theory, whereas the semantics of declared 
modes is defined as a strict partial order relation 2 among the solutions. The mode 
declarations essentially provide a selection mechanism among the alternative solu- 
tions, thus making fixed-point computation more flexible. We formally present the 
semantics of mode declaration in a tabled Prolog program, and further show the 
correctness of its operational semantics in tabled resolution. 

The new mode-declaration scheme, coupled with recursion, provides an attractive 
platform for making dynamic programming simpler: there is no need to define the 
value of an optimal solution recursively, instead, defining the value of a general solu- 
tion suffices. The optimal value, as well as its associated solution, will be computed 
implicitly and automatically in a tabled Prolog system that uses our new mode 
declaration scheme and modified variant checking. Thus, dynamic programming 
problems are solved more elegantly and more declaratively. 

We have successfully implemented our tabled resolution as well as the mode dec- 
laration scheme in the ALS Prolog, a commercial Prolog system. To implement the 
mode declaration scheme, no change is required to the tabled resolution mechanism; 
therefore, the same idea can also be applied to other tabled Prolog systems. Our 
experimental results show that the mode declaration scheme improves both time 
and space performance while solving dynamic programming problems. 

The rest of the paper is organized as follows: Section 2 introduces tabled logic 
programming and our new tabled resolution scheme, dynamic reordering of alter- 
natives (DRA) [Guo and Gupta 2001], for efficient fixed-point computation. Sec- 
tion 3 presents a mode declaration scheme for tabled predicates, shows how it 
affects fixed-point computation, and describes its implementation. Section 4 gives 
a detailed demonstration of how dynamic programming can benefit from this new 
scheme. Section 5 presents the performance results w.r.t. some dynamic program- 
ming benchmarks. Finally, section 6 gives our conclusions. 

2. COMPUTING FIXED POINTS VIA TABLED RESOLUTION 
2.1 Tabled Logic Programming (TLP) 

Traditional logic programming systems (e.g., Prolog) use SLD resolution [Lloyd 
1987] with the following computation strategy: subgoals of a resolvent are solved 
from left to right and clauses that match a subgoal are applied in the textual 



2 A strict partial order relation is irreflexive and transitive. 
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order they appear in the program. It is well known that SLD resolution may lead 
to non-termination for certain programs, even though an answer may exist via 
the declarative semantics. That is, given any static computation strategy, one can 
always produce a program in which no answers can be found due to non-termination 
even though some answers may logically follow from the program. In case of Prolog, 
programs containing certain types of left-recursive clauses are examples of such 
programs. 

Tabled logic programming [Tamaki and Sato 1986; Chen and Warren 1996] elim- 
inates such infinite loops by extending logic programming with tabled resolution. 
The main idea of tabled resolution is to memoize the answers to some calls and 
use the memoized answers to resolve subsequent variant calls. Tabled resolution 
adopts a dynamic computation strategy while resolving subgoals in the current re- 
solvent against matched program clauses or tabled answers. It keeps track of the 
nature and type of the subgoals; if the subgoal in the current resolvent is a variant 
of a former tabled call, tabled answers are used to resolve the subgoal; otherwise, 
program clauses are used following SLD resolution. 

The main advantages of tabled resolution are that a TLP system terminates more 
often by computing fixed-points, avoids redundant computation by memoing the 
computed answers, and keeps the declarative and procedural semantics consistent 
for pure logic programs with bounded-size terms. A tabled logic programming 
system can be thought of as an engine for efficiently computing fixed-points, which 
is critical for many practical applications. Tabled logic programming (TLP) systems 
have been put to many innovative uses, such as model checking [Ramakrishnan et al. 
1997] and non-monotonic reasoning [Swift 1999], due to their highly declarative 
nature and efficiency. 

In a tabled logic programming system, only tabled predicates are resolved using 
tabled resolution. Tabled predicates are explicitly declared as follows: 

:- table p/n. 

where p is a predicate name and n is its arity. A global data structure table is 
introduced to memoize the answers of any subgoals to tabled predicates, and to 
avoid any recomputation. 

2.2 Related Works 

The first tabled resolution scheme, called OLDT [Tamaki and Sato 1986], was 
proposed in 1986 by Tamaki and Sato for avoiding some of the non-termination 
problems during evaluation of definite logic programs. The basic idea of OLDT 
is to maintain a global table data structure to remember the queries seen so far 
and their corresponding answers produced so far. Such a predicate call that has 
been recorded in the table is referred to as a tabled call. Any answers to a tabled 
call will be recorded in the table, and referred to as tabled answers. OLDT reso- 
lution usually maintains multiple computation trees, in parallel, for computing the 
fixed-point, where each computation tree uniquely corresponding to one tabled call. 
Subsequently, this work has been extended to SLG resolution [Swift and Warren 
1994; Chen et al. 1995; Chen and Warren 1996] for general logic programs with 
negation. The XSB system [Chen and Warren 1996] is an implementation of SLG 
resolution which supports well-founded semantics [Chen and Warren 1993; Chen 
et al. 1995]. The XSB system has bee implemented atop the Warren Abstract Ma- 
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chine (WAM) [Ait-Kaci 1991]. As is well known, compiling to the WAM instruction 
set is a standard way of implementing high performance logic programming sys- 
tems. The implementation of the XSB system involved many non-trivial changes 
to the WAM, and was a very substantial engineering effort [Sagonas and Swift . 
1998]. 

The huge implementation effort needed for implementing OLDT and SLG can be 
avoided by choosing alternative methods for tabled resolutions that maintain a sin- 
gle computation tree similar to traditional SLD resolution, rather than maintaining 
a, forest of SLD trees. SLDT resolution [Shcn ct al. 2001; Zhou ct al. 2000] was the 
first attempt in this direction. The main idea behind SLDT is to steal the back- 
tracking point — using the terminology in [Shen et al. 2001; Zhou et al. 2000] — of 
the previous tabled call when a variant call is found, to avoid exploring the current 
recursive clause which may lead to non-termination. However, because the variant 
call avoids applying the same recursive clause as the previous call, the computation 
may be incomplete. Thus, repeated computation of tabled calls is required to make 
up for the lost answers and to make sure that the fixed-point is complete. SLDT 
does not propose a complete theory regarding when a tabled call is completely 
evaluated, rather it relies on blindly recomputing the tabled calls to ensure com- 
pleteness. SLDT resolution was implemented in early versions of B-Prolog system. 
However, recently this resolution strategy has been discarded, instead, a variant of 
DRA resolution [Guo and Gupta 2001] has been adopted in the latest version of 
B-Prolog system [Zhou and Sato 2003]. 

2.3 Dynamic Reordering of Alternatives (DRA) 

The DRA resolution [Guo and Gupta 2001] computes a fixed-point in a very similar 
way as a goal-directed bottom- up execution of logic programs [Lloyd 1987]. Its main 
idea is to dynamically identify looping alternatives from the program clauses, and 
then repetitively apply those alternatives until no more answers can be found. A 
looping alternative refers to a clause that matches a tabled call and will lead to a 
resolvent containing a recursive variant call. The DRA resolution requires that not 
only the answers to variant calls are tabled, the alternatives leading to variant calls 
are also memorized in the table, which is essentially different from all the previous 
tabled resolution strategies. 

As shown in Figure 1, the computation of a tabled call (e.g., reach(a,X)) is 
divided into three stages: normal, looping and complete. The purpose of the normal 
stage is to find all the looping alternatives (clause (1) leading to a variant subgoal 
reach(a, Z) ) and record all the answers generated from the non-looping alternatives 
(clause (2)) into the table. The new_answer label indicates that the new answer 
generated from that successful path should be added into the tabic. Then, in 
the looping stage only the looping alternative (clause (1)) is applied repeatedly 
to consume new tabled answers until a fixed-point is reached, that is, no more 
answers for reach(a,X) can be found. Afterwards, the complete stage is reached. 
As a result, the query :- reach(a,X) returns a complete answer set X=b, X=c and 
X=a, albeit the predicate is defined left-recursively. 

The DRA tabled resolution adopts a dynamic computation strategy by keeping 
track of the type of the current resolvent. If the current resolvent is a non-tabled 
call (e.g., all the calls to the predicate arc/2), then the traditional SLD resolution 
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Fig. 1. DRA Resolution for Example 1(a) 

is applied. Otherwise, if it is a tabled call, then the first occurrence of a tabled call 
in the computation is referred to as the master call; subsequent variant calls are 
called slave calls in DRA resolution. The master tabled call (e.g., reach (a, X)) is 
responsible for exploring the matched clauses, manipulating execution states, and 
repeatedly applying its corresponding looping alternatives in order to collect the 
tabled answers, whereas the slave tabled call (e.g., reach(a,Z)) only consumes 
tabled answers if there are any in the table. 

In DRA resolution, the procedure of computing fixed-points of a definite logic 
program mimics the semi-naive bottom-up computation strategy [Balbin and Ra- 
mamohanarao 1987], whenever a looping alternative is applied again, the variant 
tabled calls only consume the incremental part of solutions in the table. 

Example 2. Consider the following tabled Prolog program with multiple looping 
alternatives: 

:- table r/2. 

r(X, Y) :- r(X, Z) , p(Z, Y) . 
r(X, Y) :- p(X, Y) . 
r(X, Y) :- r(X, Z) , q(Z, Y) . 
p(a, b) . p(b, c) . q(c, d) 

:- r(a, Y) . 

Figure 2 gives the computation tree produced with the DRA scheme for example 2 
(note that the labels on the branch refer to the clause used for creating that branch) . 
Both clause (1) and clause (3) need to be tabled as looping alternatives for the tabled 
call r(a,Y). The second alternative is a non-looping alternative that produces an 
answer for the call r(a,Y) which is recorded in the table (denoted by the operation 
new_answer in the figure). The query call r(a,Y) is a master tabled call (since it 
is the first occurrence), while all the occurrences of r(a,Z) are slave tabled calls 
(since they are calls to variant of r(a,Y)). When the call r(a,Y) enters its looping 
state, it keeps applying the looping alternatives repeatedly until the answer set does 
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not change any more, i.e., until r(a,Y) is completely evaluated. Note that if we 
added two more facts: p(d,e) and q(e,f), then we will have to go through the 
two looping alternatives one more time to produce the answers r (a, e) and r (a, f ) . 
Each time a looping alternative is invoked, only incremental tabled solutions are 
consumed. 



^^^^^^^^^^^ r 
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Fig. 2. DRA Resolution for Example 2 



2.4 A Semi-naive Algorithm for DRA 

We next give a meta-interpreter to describe how DRA works operationally. To 
keep the presentation and the mcta-intcrprctcr simple and clear, we assume that 
there are no nested tabled calls dependent on each other and we ignore any further 
optimizations except the incremental consumption for the semi-naive algorithm. 
We also assume that the table exists as a global data structure. 

As shown in Figure 3, the solve/1 predicate is the entry point to the meta- 
interpreter and takes as input the goal to be executed. The goal clause (A, CI) non- 
deterministically finds the matching clause, CI, for the goal A, and then setCurrentAlt (A , CI) 
records the current alternative CI associated with A in a temporary global database. 
The goal tabled (A) checks whether A has been declared as tabled or not, state (A, X) 
checks to see whether A's execution status is X (one of normal, looping, or complete), 
while the goal setState(A,X) changes the execution state of the goal A to the state 
X. The goal addTableAns (A) adds an answer for goal A to the table (if it is not 
already present), while the goal look_up_table (A) looks up answers for A that have 
been recorded so far in the table. The goal addLoopAlt(A,Cl) finds the current 
alternative of A (which was previously recorded by setCurrentAlt (A, CI)), and 
then tables it as a looping alternative for A. The goal getLoopAlt (A, La) nonde- 
tcrministically finds the next looping alternative, La, from the list of A's looping 
alternatives. 

The meta-interpreter in Figure 3 is pretty self-explanatory A non-tabled goal 
is computed as in standard Prolog, with leftmost-first selection rule (line 2) and 
a depth-first search rule (line 27). A tabled call, on the other hand, is resolved 
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(1) solve (true) . 

(2) solve((A,B)) :- solve (A), solve(B). 

(3) solve (A) :- 



(4) (tabled(A) -> 

(5) (state (A, normal) -> 7,7, A in normal state 

(6) (type (A, master) -> '/,'/, A is a master call 

(7) (clause(A.Cl) -> 

(8) setCurrentAlt(A,Cl) , solve (CI), addTableAns(A) 

(9) ; setState(A, looping), solve (A) 

(10) ) 

(11) ; addLoopAlt (A) , '/,'/, A is a slave call 

(12) look_up_table (A) 

(13) ) 

(14) ; (state(A, looping) -> 7,7, A in looping state 

(15) (type(A, master) -> 7,7, A is a master call 

(16) (getLoopAlt(A, La) -> 

(17) solve(La), addTableAns(A) 

(18) ; (isNewSolFnd(A) -> 

(19) solve(A) 

(20) ; setState(A, complete) 

(21) ) 

(22) ) 

(23) ; look_up_table(A) 7,7, A is a slave call 

(24) ) 

(25) ; look_up_table(A) 7,7, A in complete state 

(26) )) 

(27) ; clause(A, CI), solve(Cl) '/.•/. non-tabled call 

(28) ) . 



Fig. 3. An algorithm for DRA resolution 

in a different manner by the DRA scheme based on its execution state (normal, 
looping or complete) and its master-slave mode. Consider a tabled goal A (line 
4). If A's execution state is normal (line 5) and it is a master call (line 6), then 
a matching clause CI for A is nondeterministically found, and the subgoals in the 
body of CI recursively solved (line 7-8). An answer for A will be added into the 
table if its matching clause CI is successfully solved (line 8). The matching clause 
CI is identified as a looping alternative if a slave call of A is found (line 11), and the 
slave call can only be resolved against tabled answers (line 12). After all matching 
clauses have been seen, A's execution state is set to looping (line 9). During the 
looping state (line 14), the master call of A retrieves and executes the collected 
looping alternatives (line 15-17); whereas the slave call of A can only consume the 
tabled answers. If no new answer is found while applying one cycle of all the looping 
alternatives w.r.t. the master call of A, the execution state is set to complete (line 
20); otherwise goal A continues to be executed (line 19) during its looping state until 
no new answer can be found. Once the tabled goal A reaches its complete state, all 
answers would have been recorded in the table, and thus only table look-ups are 
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used for resolving subsequent variant calls to A. 

To make the algorithm efficient, we introduce an incremental consumption strat- 
egy for the predicate look_up_table/l to mimic semi- naive evaluation of logic 
programs [Balbin and Ramamohanarao 1987]. Incremental consumption refers to 
avoiding re-consuming older tabled answers which have already been consumed ear- 
lier by the same slave tabled calls. Each looping alternative maintains two pointers, 
called begin and end, which divide the tabled answer list into three parts: old an- 
swers, current answers, and new answers. Old answers are those tabled answers 
that were consumed during the previous round of exploring the looping alternative; 
current answers can be consumed during the current exploration; and new answers 
are kept for the next round of consumption. The answers between the pointers 
begin and end constitute the incremental answer set to be consumed in the cur- 
rent round. The incremental answer set is updated dynamically whenever a looping 
alternative is picked up for exploration. Therefore, the predicate look_up_table/l 
only consumes the incremental answer set. 

2.5 Experiments 

The DRA resolution builds the computation tree as in normal Prolog execution 
based on SLD, however, when a variant tabled call is encountered, the branch that 
leads to that variant call is tabled as a looping alternative, and later applied again 
during the looping state. This has the same effect as shifting branches with variant 
calls to the right of the SLD tree to avoid exploring potentially non-terminating 
branches. Because of this simplicity, the DRA resolution can be incorporated very 
easily and without sacrificing efficiency in an existing Prolog system. This can have 
important consequences, given that tabling is so important for many serious ap- 
plications of logic programming (e.g., model checking [Ramakrishnan et al. 1997]). 
The simplicity of our scheme guarantees that execution is not inordinately slowed 
down (e.g., in the previous B-Prolog tabled system [Zhou ct al. 2000], a tabled call 
may have to be re-executed several times to ensure that all answers are found) , nor 
considerable amount of memory used (e.g., in the XSB tabled system [Chen and 
Warren 1996] a large number of stacks/heaps may be frozen at any given time), 
rather, the raw speed of the Prolog's WAM engine is available to execute even 
those programs that contain variant calls. The new tabling scheme allows one to 
incorporate tabling in an existing logic programming system with very little effort. 
Using the DRA scheme we were able to incorporate tabling in the commercial ALS 
Prolog system [ALS ] in a few man-months of work. The time efficiency of our 
tabled ALS (called TALS) system is comparable to that of the XSB system. The 
space efficiency of our system is better than that of XSB system. 

A preliminary implementation of DRA in the ALS Prolog system has been com- 
pleted. Table I gives the comparison of running times (in seconds) between XSB 
and TALS for various benchmarks. These benchmarks are distributed with XSB 
and most of them table multiple predicates, many of whom manipulate structures. 
In general, the time performance of TALS is worse than that of XSB. That is 
mainly because SLG resolution has been implemented by a combination of com- 
putation suspension via stack freezing and maintaining a forest of SLD trees. Due 
to the computation suspensions and resumption, XSB avoids reconstructing execu- 
tion environment for applying looping alternatives, which is typically recomputed 
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Benchmarks 


TALS 


XSB 


cs_r 


0.37/29.8 


0.20/58.3 


disj 


0.25/18.7 


0.05/54.2 


kalah 


0.20/37.0 


0.05/97.1 


peep 


0.47/24.0 


0.18/376.3 


Pg 


0.29/23.9 


0.05/150.5 


read 


0.62/35.8 


0.23/616.7 


sg 


0.03/27.4 


0.08/48.3 



Table I. Running-time(Seconds)/Space-usagc(KB) 

in TALS since looping alternatives have to be applied again to ensure the comple- 
tion of fixed-point computation. On the other hand, due to this maintenance of 
forest of SLD trees and freezing of stacks, XSB cannot be implemented in the same 
way as SLD resolution using a simple stack-based memory structure. Consequently, 
the freezing of stacks results in significant space overheads. It should also be men- 
tioned that DRA has been implemented on top of ALS system without modifying 
the compiler. XSB includes tabling in compiling stage, which may have significant 
impact on performance. 

Tables I also compares the space usage between TALS and XSB systems. The 
space includes total stack and heap space used as well as space overhead to support 
tabling. The space overhead to support tabling in case of TALS includes table 
space, the extra space needed to record looping alternatives and extra fields for 
keeping track of the types of tabled calls. In case of XSB, the figure includes the 
table space and space used for suspension in SLG-WAM [Swift and Warren 1994]. 
As can be noticed from Table I, the space performance of TALS is significantly 
better than that of XSB (for some benchmarks, e.g., peep, pg and read, it is orders 
of magnitude better). 

3. FLEXIBLE FIXED POINT COMPUTATION VIA MODES 

There are many situations in which a fixed-point contains a large number or even 
infinite number of solutions (for example 1(b)). In these cases, a fixed-point com- 
putation engine may not be efficient enough or feasible at all. In this section, 
we present a mode-declaration scheme [Guo and Gupta 2004] which provides the 
users the capability to reduce a fixed-point from a large solution set to a preferred 
small one, or from an infeasiblc infinite set to a finite one. The mode declaration 
scheme can be characterized as a meta-level mapping operation over the original 
fixed-point. 

3.1 Mode Declarations 

The fixed-point reduction can be achieved by a mode declaration for tabled predi- 
cates, which is described in the form of 

:- table q(mi, m n ) . 
where q/n is a tabled predicate name, n > 0, and each rm has one of the forms as 
defined in Table II. 

In order to find out how modes will affect fixed-point computations, we have to 
better understand the function of variant checking in tabled resolution. Variant 
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Modes 


Informal Semantics 


+ 

min 

max 


an indexed argument 
a non-indexed argument 
a minimum non-indexed argument 
a maximum non-indexed argument 



Table II. Built-in Modes for Tabled Predicates 



checking is a crucial operation for tabled resolution as it leads to avoidance of non- 
termination. It is used to differentiate between the various tabled calls as well as 
their answers. While computing the answers to a tabled goal p with tabled resolu- 
tion, if another tabled subgoal q is encountered, the decision regarding whether to 
consume tabled answers or to try program clauses depends on the result of variant 
checking. If q is a variant of p, the variant subgoal q will be resolved by unify- 
ing it with tabled answers, otherwise, traditional Prolog resolution is adopted for 
q. Additionally, when an answer to a tabled goal is generated, variant checking is 
used to check whether the generated answer is variant of an answer that is already 
recorded in the table. If so, the table is not changed; this step is crucial in ensuring 
that a fixed-point is reached. 

The main purpose of mode declaration is to classify the predicate arguments 
into two types: indexed and non-indexed. Only indexed arguments are used for 
variant checking while collecting answers for the table; for each tabled call, any 
answer generated later for the same value of the indexed arguments is discarded 
because it is a variant, w.r.t. the indexed arguments, of a previously tabled an- 
swer. Consider again the reachability program in Example 1(b). Suppose we 
declare the mode as ":- table reach (+, + ,-)"; this means that only the first 
two arguments of the predicate reach/3 are used for variant checking. The new 
computation of the query reach(a,Y,E) is shown in Figure 4. Since only the 
first two arguments of reach/3 are used for variant checking, the last two answers 
"Y=b, E=[(a,b) , (b,a) , (a,b)]" and "Y=c, E=[(a,b) , (b,a) , (a,c)]", shown on 
the rightmost two sub-branches, are variant answers to "Y=b, E=[(a,b)]" and 
"Y=c, E=[(a,c)]" respectively. Therefore, no new answers are added into the 
table at those points. The computation is then terminated properly with three an- 
swers. As a result, each reachable node from a has a simple path as an explanation. 

The mode directive table makes it very easy and efficient to extract explanation 
for tabled predicates. In fact, our strategy of ignoring the explanation argument 
during variant checking results in only the first explanation for each tabled answer 
being recorded. Subsequent explanations are filtered by our modified variant check- 
ing scheme. This feature ensures that those generated explanations are concise and 
that cyclic explanations are guaranteed to be absent. For the reachability instance 
shown in Figure 4, each returned path is simple so that all arcs are distinct. 

Essentially, if we regard a tabled predicate as a function, then all the non-indexed 
arguments are uniquely defined by the instances of indexed arguments. For the 
previous example, the third argument of reach/3 returns a single path depending 
on the first two arguments. Therefore, variant checking should be done w.r.t. 
only indexed arguments during tabled resolution. From this viewpoint, the mode 
declaration makes tabled resolution more efficient and flexible. More importantly, 
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reach (a, Y, E) 




Tabled 
Subgoals 


Answers 


Looping 
Alternatives 


reach (a, Y, E ) 


reach{a,b, [ (a,b) ] ) 
reach (a, c, [ (a, c) ] ) 
reach {a, a, [ (a,b) , (b, a) ] ) 


(1) 



Fig. 4. DRA Resolution with Mode Declaration 

this declaration scheme is especially useful in reducing an infinite set of solutions 
to a finite one for some practical uses, or to reduce a large finite set of solutions to 
an optimized smaller set as shown next. 

3.2 Declaration of Aggregates 

The mode directive table can be further extended to associate a non-indexed ar- 
gument of a tabled predicate with some aggregate constraint. With the mode a 
non-indexed argument for each tabled answer only records the very first instance. 
This "very first" property can actually be generalized to support other preferences, 
e.g., the minimum value with mode min (or the maximum with mode max), in which 
case the global table will record answers with the value of that argument as small 
(or great) as possible. That is, a tabled answer can be dynamically replaced by 
a new one with smaller (or greater) value during the computation. Note that we 
only enumerate two typical aggregates as examples, other aggregates, such as sum, 
average, or even a user-defined one, can be used as well. 

The aggregates, min and max, are specified via mode declarations as shown in 
Table II). Both modes imply that the declared arguments are non- indexed. The 
aggregates can be used to specify optimization problems more elegantly. For in- 
stance, in the code shown in example 3 for searching for shortest paths, instead of 
defining the shortest path directly, we only need to specify what is the definition 
for a general path. Clauses (2) to (5) make up the core program defining the path 
relation and a directed graph with a set of edges; Clause (1) specifies the predicate 
path/4 to be optimized and gives the criteria regarding how it should be optimized. 
The mode declaration path(+, + ,min,-) means that only the first two arguments 
(pair of nodes) are used for variant checking when an answer is generated, and a 
minimum value (the shortest path) is expected for the third argument. Arguments 
with different modes are tested in the following order during variant checking of a 
recently generated answer: (i) the indexed argument with '+' mode has the highest 
priority to be checked to identify whether it is a new answer. If that is the case, a 
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new tabled entry is required to record the answer; otherwise a tabled answer with 
the same indexed arguments is found, (ii) This tabled answer is then compared 
with the recently generated one w.r.t the argument with the optimum mode 'min'; 
if the new answer has a smaller value for this argument, then a replacement of the 
tabled answer is required such that the tabled answer keeps the minimum value 
as expected for this argument, (iii) The last argument with mode '-' will not be 
used for variant checking; if a replacement of a tabled answer happens, then the 
argument will be replaced as well; otherwise, the recently generated answer as well 
as its fourth argument are discarded. 

Example 3. Consider the following program searching for a shortest path, where 
path(X,Y,D,L) denotes a path from X to Y with the distance D and the path route 
L. 



:- table path(+, +, min, -) . (1) 

path(X, X, 0, []) . (2) 

path(X, Y, D, [e(X, Y)]) :- edge(X, Y, D) . (3) 

path(X, Y, D, [e(X, Z) I P]) :- 

edge(X, Z, Dl) , path(Z, Y, D2, P) , 

D is Dl + D2. (4) 

edge(a,b,4) . edge(b,a,3). edge(b,c,2). (5) 

:- path (a, X, D, P) . (6) 



Example 3 shows that even though the core program defines a general path, with 
mode declaration, the predicate path/ 4 can be easily upgraded to an optimization 
predicate. As long as the tabled Prolog engine is set to compute the fixed-point 
semantics for logic programs, the shortest path under consideration will always be 
found. Intuitively, given a tabled call C, the DRA resolution first finds all the 
answers for C using clauses not containing variant calls. Once this set of answers 
is computed and tabled, it is treated as a set of facts, and used for computing 
rest of the answers from the clauses leading to variant calls (looping alternatives). 
Whenever an answer to C is generated, it will be selectively added to the table either 
as a new entry or as a replacement based on the defined mode of the corresponding 
predicate. The process stops when no new answers can be computed via the looping 
alternatives, i.e., a fixed point is reached. In this regard, with the assistance of mode 
declaration and tabled resolution, the computation of program clauses only defining 
general solutions will still produce the optimal solution. 

3.3 Operational Semantics 

The operational semantics of a tabled program is dependent on tabled resolution 
[Chen and Warren 1993; Zhou et al. 2000; Guo and Gupta 2001], which can be for- 
malized based on the Herbrand model [van Emden and Kowalski 1976; Lloyd 1987] 
and fixed-point theory. In spite of having different tabled resolution, a tabled Pro- 
log can be thought of as an engine for efficiently computing the least fixed-points. 
The procedure of computing fixed-points of a definite logic program in DRA resolu- 
tion mimics the bottom-up computation strategy as follows. For the consideration 
of clarity and simplicity, we ignore any optimization used in DRA resolution (e.g. 
incremental consumption for simulating semi-naive bottom-up computation). 
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We use the following notational conventions: P is used to denote a tabled logic 
program, Bp to denote the Herbrand base of P, 2 B to denote the set of all 
Herbrand interpretations of P, a ground instance (e.g., a ground atom, a ground 
instance of a clause) to denote an instance without involving any variable. Note 
that cj is the first infinite ordinal, and (T \ n) (x) to denote applying the mapping 

n 

T n times as J-{J-{- ■ ■ F{x) ■■■)). 

Definition 1. Let P be a logic program and Bp its Herbrand base. Let de- 
note the empty set. We define a meta-level procedure Tp : 2 Bp — > 2 Bp . Given a 
Herbrand interpretation I, T P (I) performs: 

1. h - 0; 

2. for each ground instance A :- A\, ■ ■ ■ , A m of a clause in P 
where {A\, ■ ■ ■ , A n } C I, do 

/o^/oU {A}; 

3. return L . 

The fixed-point semantics of P can be described as Tp j lo(%) [Lloyd 1987] . 

We next show that how mode declaration affects the fixed-point semantics of a 
logic program. One key ingredient for the mode declaration scheme to be applicable 
is the optimal- substructure property 3 , that is, the optimal solution to a tabled 
call contains optimal solutions to its tabled sub-calls. Typical examples of such 
problems are those for dynamic programming. For simplicity, we assume that 
for any tabled predicate, there is at most one optimization mode, 'min' or 'max', 
in the mode declaration. Tabled predicates whose multiple arguments have an 
optimization mode can be handled by combining them into one via program clause 
transformation. Additionally, we assign non- indexed modes different priorities, i.e., 
'min' and 'max' have higher priorities than '-'. 

Note that a tabled predicate without explicit mode declaration has a default one 
with all indexed modes '+'. Although mode declarations are only allowed for tabled 
predicates, non-tabled predicates can also be simply treated as having implicitly 
declared indexed mode '+' for all arguments. Thus, in the rest of this subsection 
we will not distinguish tabled predicates from non-tabled ones, and each predicate 
defined in a tabled logic program is associated with a mode declaration. 

Definition 2. Let q/n be a predicate with a mode declaration q(m\ ,TO2, •• • ,m n ) 
in a tabled logic program P. Let the arguments ran, m^, ■ ■ ■ , rriik (0 < k < n) have 
the mode '+ ' such that 1 < i\ < i2 < ■ ■ ■ < ik < n; let nij be the argument with 
the highest priority non-indexed mode if there are non- zero arguments in q/n with 
non-indexed modes. We define two functions K q / n and O q / n as follows: given a 
ground atom q(ai, a 2 , ■ ■ ■ ,a n ), 

£g/n(<?(ai> 0-2, ■ ■ ■ , O-n)) = «i2, ■ ■ ■ , a%k)\ 

O q / n {q{ai,a 2 , ■ ■ ■ ,a„)) = aj, if mj exists. 

3 A problem has optimal-substructure property if its optimal solution can be expressed in terms 
of optimal solutions of its subproblcms. 
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We say two ground atoms, t\ and t 2 , of q/n comparable if and only if )C q / n (ti) = 

The function K, q / n is used to return a sequence of indexed arguments in a left- 
to-right order, whereas O q / n returns a non-indexed argument with the highest 
priority. We say two ground atoms of q/n are comparable if and only if these two 
atoms have the same indexed arguments. We abbreviate tC q / n and O q / n to /C and 
O, respectively, whenever the predicate is obvious from the context. Thus, we have 
a preference relation defined as follows. 

Definition 3. Let P be a logic program. A preference relation in P is a strict 
partial order relation -<p s.t. for any two ground atoms A\ and A2 of a predicate 
q/n in P, A\ <p A2 if both of the followings are true: 

-K{A l ) = K{A 2 ); 

— cases the non-indexed mode with the highest priority in q/n of 
min: 0{A X ) > 0{A 2 ); 
max: 0{A X ) < 0(A 2 ); 

— : A 2 is generated earlier than A\ during tabled resolution. 

We abbreviate -<p to ^ whenever the tabled logic program is obvious from the 
context. It should be mentioned that the semantics of mode '— ' is heavily dependent 
on the order in which the answers are generated, which is decided by the tabled 
resolution procedure used. For Example 3, the preference relation -< is the set 

{ path(a, a, 7, _) ~< path(a, a, 0, _), 

path(a, a, 14, _) ~< path(o, a, 0, _), path(a, a, 14, _) -< path(a, a, 7, _), 
path(a, b, 11, _) -< path(a, b, 4, _), 

path(a, b, 18, _) -< path(a, b, 4, _), path(a, b, 18, _) ~< path(a, b, 11, _), 
} 

where the numbers 0, 7, 11, ... are the possible distances for their corresponding pair 
of nodes, and '_' means any ground term from the Herbrand universe. Note that 
no atoms of the non-tabled predicate edge/3 are in the preference relation. This is 
because each non-tabled predicate is implicitly declared to have the index mode '+' 
for all its arguments; therefore, none such predicate can satisfy the second condition 
of Definition 3. Similarly, all ground atoms of non-tabled predicates are optimized 
according to the following definition. 

Definition 4. Let P be a logic program and I be one of its Herbrand interpre- 
tations; We say that A is an optimized ground atom, abbreviated as an optimized 
atom, in I if there does not exist any other ground atom A\ £ I s.t. A -< A\. 



4 A strict partial order relation is irreflexive and transitive. 
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Definition 5. Let P and Bp be a logic program and its Herbrand base. We 
define a meta-level procedure T p : 2 Bp — > 2 Bp . Given a Herbrand interpretation I, 
T P {I) performs: 

l. Jo «- 0; 

for eac/i ground instance A :- A\, ■ ■ ■ , A m of a clause in P 
where {A\ , ■ ■ ■ , A n } C I, do 
2a. I «- Jo U {A}; 

56. 7 <- Jo - {ai G Jo : 3a 2 £ J s.t. Oi -« a 2 } w 
5. return 7 - 

Thus, the fixed-point semantics of P can be described as T p f u(0). 

Dcf. 5 gives the fixed-point semantics for a tabled logic program with mode decla- 
ration. The statement (*) shows how non-indexed modes affect the the procedural 
semantics of the core program through the preference relation -< . 

Proposition 1. Let P be a tabled logic program. For any atom A e T P | n(0), 
where n>0, A is an optimized atom in T p j n(0). 

Proof: This can be easily shown by mathematical induction on n, mainly using 
the result of step 2b in Definition 5: 

Jo «- Jo - {ai G Jo : 3a 2 G J s.t. ai -< a 2 }, 
so that any atom A in the resulting I is an optimized atom according to Defini- 
tion 4. □ 

Proposition 2. Let P be a tabled logic program. If A is an optimized atom in 
Tp | n(0), then we have A G T p f n(0), /or any n > 0. 

Proof: The proof is based on a mathematical induction on n. 

Base case: Consider n — 0. Since Tp | 0(0) is an empty set, the proposition is 

vacuously true. 

Inductive Case : Assume that the proposition is true for some i > 0. We consider 
an optimized atom A G Tp | (i + 1)(0). A is obviously an optimized atom in 
T' p t (i + 1)(0) as well due to the fact that T p | (i + 1)(0) C T P | (i + 1)(0). Next, 
we complete the proof by showing A G T p j (i + 1)(0). According to Definition 1, 
there exists a ground instance A m (for some m > 0) of a clause in P where 

{Ai, ...,A m } C Tp | i(0). Based on the optimal-substructure property, Ai, ...,A m 
must be optimized atoms in Tp f i(0). Following the induction assumption, wc 
have {Ai, A m } e T p f i(0). Therefore, A satisfies the conditions specified in 
Definition 5; we have A G T P | (i + 1)(0). □ 

PROPOSITION 3. Let P be a tabled logic program. If A e T P ] n(0), t/ien we 
/iaue t/iat A is an optimized atom in Tp f n(0), /or any n > 0. 

Proof: We can easily get A G Tp | n(0) due to the fact that T P f n(0) is a subset 
of Tp | n(0). Assume that A' is an optimized atom in Tp | n(0) and A -< A'. 
Based on Proposition 2, we have A 1 G T p j n(0), which is a contradiction with the 
fact that A G T P j n(0) since A -< A'. Therefore, A must be an optimized atom in 
Tp t n(0). □ 
Thus, we have the following main result showing the correctness of our mode 
declaration scheme for solving optimization problems with optimal-substructure 
property. 
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Theorem 4. Let P be a tabled logic program. A e T p | w(0) i/ and only if A is 
an optimized atom in Tp j a>(0). 

Proof: The proof follows trivially from Proposition 2 and Proposition 3. □ 
3.4 Implementation 

The mode declaration scheme has been implemented in the authors' TALS system, a 
tabled Prolog system implemented on the top of the WAM engine of the commercial 
ALS Prolog engine [ALS ]. No change is required to the DRA resolution mechanism; 
therefore, the same idea can also be applied to other tabled Prolog systems such as 
XSB and B-Prolog. 

In the TALS system, the global data structure table is efficiently implemented 
thanks to the trie data structure [Rao et al. 1999]. The organization of the table can 
be abstractly described as a two-level hierarchical structure. The first level is used 
to organize different tabled calls indexed by their corresponding predicates names 
and arities; whereas the second level is used to organize tabled answers indexed by 
the tabled calls. Variant checking is the main operation used to locate the correct 
table position to access the table. 

Two major changes to the global data structure table are needed to support 
mode declarations. First, each table predicate is associated with a new item mode, 
which is represented as a bit string. The default mode for each argument in a 
table predicate is '+'. Second, the answers to a tabled call are selectively recorded 
depending on its mode declaration. The declared modes essentially specify the user 
preferences or selection constraints among the answers. When a new answer to 
a tabled goal is generated, variant checking on indexed arguments is invoked to 
determine whether the answer is variant to a previously tabled one. If that is the 
case, declared modes on non-indexed arguments are used to select a better answer 
to table; otherwise, a new table entry is added to record the answer. In fact, if an 
indexed argument is instantiated in advance before a tabled goal is called, variant 
checking on this indexed argument can be avoided since its value is same for all the 
answers; furthermore, it is not necessary to record the pre-instantiated value with 
each tabled answer because the same value has already been stored in the tabled 
call entry. This optimization leads to improvements on both time and space system 
performance. 

Another important implementation issue is the replacement of tabled answers. In 
the current TALS system, if the tabled subgoal only involves numerals as arguments, 
then the tabled answer will be completely replaced if necessary. If the arguments 
involve structures, however, then the answer will be updated by a link to the new 
answer. Space taken up by the old answer has to be recovered by garbage collection 
(the ALS Prolog's garbage collector has not yet been extended by us to include table 
space garbage recovery). As a result, if arguments of tabled predicates are bound 
to structures, more table space may be used up. 

4. A DECLARATIVE METHOD FOR DYNAMIC PROGRAMMING 

In the dynamic programming paradigm the value of an optimal solution is recur- 
sively defined in terms of optimal solutions to subproblems. Such dynamic program- 
ming definitions can be very tricky and error-prone to specify due to the involvement 
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of both optimization and recursion. In this section, we presents a novel, elegant 
method based on tabled Prolog programming that simplifies the specification of 
such dynamic programming solutions. With the mode-declaration scheme, there is 
no need to define the value of an optimal solution recursively, instead, defining a 
general solution suffices for dynamic programming. The optimal value as well as its 
corresponding concrete solution can be derived implicitly and automatically using 
tabled Prolog systems. 

4.1 Dynamic Programming with TLP 

Dynamic programming algorithms are particularly appropriate for implementation 
with tabled logic programming [Warren 2004]. Dynamic programming is typically 
used for solving optimization problems. It is a general recursive strategy in which 
optimal solution to a problem is defined in terms of optimal solutions to its subprob- 
lems. Dynamic programming, thus, recursively reduces the solution to a problem to 
repetitively solving its subproblcms. Therefore, for computational efficiency it is es- 
sential that a given subproblem is solved only once instead of multiple times. From 
this standpoint, tabled logic programming dynamically incorporates the dynamic 
programming strategy [Warren 2004] in the logic programming paradigm. TLP sys- 
tems provide implicit tabulation scheme for dynamic programming, ensuring that 
subproblems are evaluated only once. 

In spite of the assistance of tabled resolution, solving practical problems with 
dynamic programming is still not a trivial task. The main step in the dynamic 
programming paradigm is to define the value of an optimal solution recursively in 
terms of the optimal solutions to the subproblcms. This definition could be very 
tricky and error-prone due to the interleaving of optimization and recursion. As 
the most widely used TLP system, XSB provides table aggregate predicates [XSB 
; Swift 1999], such as bagMin/2 and bagMax/2, to find the minimal or maximal 
value from tabled answers respectively. Those predicates are helpful in finding the 
optimal solutions, and therefore in implementing dynamic programming algorithms. 
However, users still have to define optimal solutions explicitly, that is, specify how 
the optimal value of a problem is recursively defined in terms of the optimal values 
of its subproblems. Furthermore, the aggregate predicates require the TLP system 
to collect all possible values, whether optimal or non-optimal, into the memo table, 
which could dramatically increase the amount of table space needed. 

We use the matrix-chain multiplication problem [Cormen et al. 2001] as an exam- 
ple to illustrate how tabled logic programming can be adopted for solving dynamic 
programming problems. A product of matrices is fully parenthesized if it is either a 
single matrix or the product of two fully parenthesized matrix products, surrounded 
by parentheses. Thus, the matrix-chain multiplication problem can be stated as 
follows (detailed description of this problem can be found in any major algorithm 
textbook covering dynamic programming) : 

Problem 1. Given a chain (Ai,A 2 , ■ ■■,A n ) ofn matrices, where fori = 1,2, ...,n, 
matrix Ai has dimension Pi-i x pi, fully parenthesize the product A\A2...A n in a 
way that minimizes the number of scalar multiplications. 

To solve this problem via dynamic programming, we need to define the cost of an 
optimal solution recursively in terms of the optimal solutions to subproblems. Let 



20 



j] be the minimum number of scalar multiplications needed to compute the 
matrix Ai.j, which denotes a sub-chain of matrices AiA i+1 ...Aj for 1 < i < j < n. 
Thus, our recursive definition for the minimum cost of parenthesizing the product 
Ai..j becomes 



As shown in Example 4, a tabled Prolog coding is given to solve the matrix-chain 
multiplication problem. The predicate scalar _cost (PL, V, PO, Pn) is tabled, 
where PL, PO and Pn are given by the user to represent the dimension sequence 
[po> Pi > •• •> Pn] , the first dimension p and the last dimension p n , respectively, and V is 
the minimum cost of scalar multiplications to multiply A\_, n ; the built-in predicate 
f indall(X,G,L) is used to find all the instances of X as a list L such that each 
instance satisfies the goal G; the predicate break(PL, PL1, PL2, Pk) is used to 
split the dimension sequence at the point of Pk into two parts to simulate the 
parenthesization; and the predicate list_min(L, V) finds a minimum number V 
from a given list L. 

Example 4. A tabled logic program for matrix- chain multiplication problems: 

:- table scalar _cost/4 . 
scalar_cost( [PI, P2] , 0, PI, P2) . 
scalar_cost( [PI, P2, P3 I Pr] , V, PI, Pn) :- 

findalKV, ( break([Pl, P2, P3 I Pr] , PL1, PL2, Pk) , 
scalar_cost(PLl, VI, PI, Pk) , 
scalar_cost(PL2, V2, Pk, Pn) , 
V is VI + V2 + PI * Pk * Pn ) , VL) , 
list_min(VL, V) . 
break([Pl, P2, P3],[P1, P2] , [P2, P3] , P2) . 
break([Pl, P2, P3, P4|Pr],[Pl, P2],[P2, P3, P4|Pr],P2). 
break([Pl, P2, P3, P4 I Pr] , [PllLl], L2, Pk) :- 
break([P2, P3, P4 I Pr] , LI, L2, Pk) . 

Consider the problem for a chain (A\, A2, As) of three matrices. Suppose that 
the dimensions of the matrices are 10 x 100, 100 x 5, and 5 x 50, respectively. We 
can give a query :- scalar _cost ( [10, 100, 5, 50], V, 10, 50) to find the 
minimum value of its scalar multiplications. As a result, V is instantiated to 7500, 
corresponding to the optimal parenthesization ((AiA 2 )j4 3 ). 

Program 4 shows that the programmer has to find the optimal value by compar- 
ing all possible multiplication costs explicitly. In fact, for a general optimization 
problem, the definition of an optimal solution could be quite complicated due to 
heterogeneous solution construction. Then, comparing all possible solutions explic- 
itly to find the optimal one can be complicated. 

4.2 A Declarative Method based on Modes 

We present a declarative method based on the mode declaration scheme to separate 
the task of finding the optimal solution from the task of specifying the general 
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dynamic programming formulation. Using our method, the programmer is only 
required to define what a general solution is, while searching for the optimal solution 
is left to the TLP system. 

The mode declaration can be used to make control of execution implicit during 
dynamic programming, making the specification of dynamic programming prob- 
lems more declarative and elegant. For the matrix-chain multiplication, instead of 
defining the cost of an optimal solution, we only need to specify what the cost for 
a general solution is. Let m[i,j] be the number of scalar multiplications needed 
to compute the matrix Ai j for 1 < i < j < n, where n is the total number of 
matrices. The recursive definition for the cost of parenthesizing A t j becomes 

m\i j] = I ° [U = j ' 

\m[i,k]+m[k + l,j]+pi-ipkPj if * < J, 

where any k € [i,j)- Thus, we have the following program shown in Example 5. 

Example 5. A tabled logic program with optimum mode declaration for matrix- 
chain multiplication problems: 

:- table scalar _cost (+, min, -, -) . 
scalar_cost( [PI, P2] , 0, PI, P2) . 
scalar_cost([Pl, P2, P3 I Pr] , V, PI, Pn) :- 

break ([PI, P2, P3 I Pr] , PL1, PL2, Pk) , 

scalar_cost(PLl, VI, PI, Pk) , 

scalar_cost(PL2, V2, Pk, Pn) , 

V is VI + V2 + PI * Pk * Pn. 

The mode declaration scalar _cost(+, min,-,-) means that only the first argu- 
ment (the list of matrix dimensions) is used for variant checking when an answer is 
generated, and a minimum value is expected from the second argument (the cost 
of scalar multiplication). Figure 5 shows a skeleton of the recursion tree produced 
by the query 

:- scalar_cost([10,100,5,50] ,V, 10,50) . 

Its first tabled answer has V=75000. However, when the second answer V=7500 
is computed, it will automatically replace the previous answer following the de- 
clared optimum mode. Therefore, there is at most one answer for the tabled call 
scalar_cost ( [10, 100,5,50] ,V, 10,50) that exists in the table at any point in 
time, and it represents the optimal value computed up to that point. 

To make the matrix-chain multiplication problem complete, we need to construct 
an optimal parenthesization solution corresponding to the minimal cost of scalar 
multiplication. This construction can be achieved with the strategy of introducing 
an extra non-indexed argument whose instantiation becomes the solution. The 
complete tabled logic program is shown below: 

Example 6. A tabled logic program for the complete matrix-chain multiplication 
problem: 

:- table scalar _cost_evid/5 . 

:- tablejnode scalar _cost_evid(+ , min, -, -, -) . 
scalar _cost_evid( [PI, P2] , 0, PI, P2, (P1,P2)). 
scalar_cost_evid([Pl, P2, P3 I Pr] , V, PI, Pn, (E1*E2)) :- 
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scalar_cost([10,100,5,50],7500,10,50) 




Fig. 5. Recursion tree for computing scalar _cost ( [10 , 100 , 5 , 50] , V , 10 , 50) 

break ([PI, P2, P3 I Pr] , PL1, PL2 , Pk) , 
scalar_cost_evid(PLl, VI, PI, Pk, El), 
scalar_cost_evid(PL2, V2, Pk, Pn, E2) , 
V is VI + V2 + PI * Pk * Pn. 



5. EXPERIMENTAL RESULTS 

Our experimental benchmarks include five typical dynamic programming examples, 
matrix is the matrix-chain multiplication problem; les is longest common subse- 
quence problem; obst finds an optimal binary search tree; apsp finds the shortest 
paths for all pairs of nodes; and knap is the knapsack problem. All tests were per- 
formed in TALS system on an Intel Pentium 4 CPU 2.0GHz machine with 512M 
RAM running RedHat Linux 9.0. 



Benchmarks 


without modes 


with modes 


matrix 


1.99 (1.0) 


1.01 (0.51) 


les 


0.80 (1.0) 


0.37 (0.46) 


obst 


0.81 (1.0) 


0.29 (0.36) 


apsp 


3.73 (1.0) 


2.71 (0.73) 


knap 


51.79 (1.0) 


35.04 (0.68) 



(a) Without evidence construction 



Benchmarks 


without modes 


with modes 


matrix 


2.74 (1.0) 


1.97 (0.72) 


les 


0.86 (1.0) 


0.55 (0.63) 


obst 


10.58 (1.0) 


0.63 (0.06) 


apsp 


6.05 (1.0) 


2.85 (0.47) 


knap 


126.25 (1.0) 


38.56 (0.31) 



(b) With evidence construction 



Table III. Running time performance comparison in Seconds (Ratio) 



Table III compares the running time performance between the programs with and 
without mode declaration. The first group of benchmarks consists of programs that 
only seek the optimal value without evidence construction, while the second group 
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consists of programs for the same dynamic programming problems with evidence 
construction. The experimental data indicates, based on the ratios in Table III, 
that the programs with mode declaration consume only 6% to 73% of the running 
time compared to corresponding programs without mode declaration. 




Fig. 6. Time Performance of Matrix-chain Multiplication 



Figure 6 shows the timing information against different input sizes for matrix- 
chain multiplication problems. Notice that the numbers on X-axis represent the 
total number of matrices to be multiplied, and the numbers on Y-axis represent the 
running time with seconds. Whether without evidence construction (Figure 6(a)) or 
with evidence construction (Figure 6(b)), the graphs indicate that the timings of the 
programs with mode are consistently better than those without mode declaration. 

The efficiency of these programs is mainly credited to two factors. First, tabled 
Prolog systems with mode declaration provides a concise but easy-to-use interface 
for dynamic programming, and it does not introduce any major overhead; mode 
declarations are flexible and powerful means of supporting meta-level manipulation 
of fixed-points; and, mode functionality is implemented at the system level rather 
than at the Prolog programming level. Second, tabled answers can be more ef- 
ficiently organized due to the mode declaration. Indeed, if an indexed argument 
is instantiated in advance before a tabled goal is called, variant checking on this 
indexed argument can be avoided since its value is the same for all the answers; fur- 
thermore, it is not necessary to record the pre-instantiated value with each tabled 
answer because the same value has already been stored in the tabled call entry. 
These optimizations lead to considerable improvement in run-time performance . 

The main disadvantage of our scheme w.r.t. efficiency is the need for frequent 
retrieval or replacement of tabled answers. This is because the optimized answer 
is dynamically selected by comparing it with old tabled answers according to the 
modes. The retrieval of a tabled answer for comparison incurs time overhead since 
information about each argument of the answer needs to be retrieved from the table. 
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For replacing a tabled answer in the current TALS system, if a tabled subgoal only 
involves numerals as arguments, then the tabled answer will be completely replaced 
if necessary. If the arguments involve structures, however, then the answer will be 
updated by a link to the new answer. Space taken up by the old answer has to be 
recovered by garbage collection later. As a result, the retrieval and replacement of 
tabled answers incurs performance overhead, especially space overhead as explained 
further below. The overhead will be minimal if the first tabled answer for each 
tabled call is optimal. 

We compare the running space performance between the programs with and with- 
out mode declaration in Table IV. For benchmarks without evidence construction, 
our experiments indicate that with mode declaration, programs consumes only 7% 
to 73% of the space compared to those without mode declaration. With evidence 
construction included, space performance can be better or worse depending on the 
problem. For the matrix and obst problems that try to find the optimal binary 
tree structure, the programs without mode declaration generate all possible answers 
and then only table the optimal one, while the programs with mode declaration and 
implicit aggregation generate all possible answers and selectively table the better 
answers until the optimal one is found. In the latter case, some non-optimal answers 
may be replaced in the table during the computation, however, the space taken by 
those old answers, including tree structures, cannot be recovered immediately. If 
the optimal answer happens to be the first tabled answer, then no other un-optimal 
answers will be recorded. This is the reason why the benchmarks matrix and obst 
(with evidence construction) with mode declaration take more space than those 
without mode, as shown in Table IV. 



Benchmarks 


without modes 


with modes 


matrix 


4.98 (1.0) 


0.93 (0.19) 


les 


78.75 (1.0) 


23.57 (0.30) 


obst 


2.65 (1.0) 


0.63 (0.24) 


apsp 


20.17 (1.0) 


14.68 (0.73) 


knap 


222.65 (1.0) 


16.29 (0.07) 


(a) Without evidence construction 


Benchmarks 


without modes 


with modes 


matrix 


9.22 (1.0) 


12.01 (1.30) 


les 


92.99 (1.0) 


44.55 (0.48) 


obst 


4.44 (1.0) 


19.37 (4.36) 


apsp 


29.90 (1.0) 


21.60 (0.72) 


knap 


399.95 (1.0) 


306.56 (0.77) 



(b) With evidence construction 



Table IV. Running space comparison: Megabytes (Ratio) 

6. CONCLUSIONS 

We presented a new tabled resolution scheme based on dynamic reordering of alter- 
natives (DRA) for efficient fixed-point computation. It works with a single SLD- 
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similar tree without suspension of any goals, and its operational semantics mimics 
the semi-naive bottom-up computation. Our scheme can be easily implemented on 
top of an existing Prolog system without modifying the kernel of the WAM engine 
in any major way. We were able to implement it on top of an existing Prolog engine 
(ALS Prolog) in a few man-months of work. Performance evaluation of our imple- 
mentation shows that it is comparable in performance to well-engineered tabled 
systems such as XSB, yet it is considerably easier to implement. 

A mode declaration scheme for tabled predicates was also introduced in TLP 
systems to aggregate information dynamically into the table. These modes provide 
a declarative method to reduce a fixed-point from a large solution set to a preferred 
small one, or from an infeasible infinite solution set to a finite one. The mode decla- 
ration classifies arguments of tabled predicates as either indexed or non-indexed. As 
a result, (i) a tabled predicate can be regarded as a function in which non-indexed 
arguments (outputs) are uniquely defined by the indexed arguments (inputs); (ii) 
concise explanation for tabled answers can be easily constructed in non-indexed 
(output) arguments; (iii) the efficiency of tabled resolution can be improved since 
only indexed arguments are involved in variant checking; and (iv) the non-indexed 
arguments of a tabled predicate can be further qualified with an aggregate mode 
such that an optimal value can be sought without explicit coding of the comparison. 

This new mode declaration scheme, coupled with recursion, provides an elegant 
method for specifying dynamic programming problems: there is no need to define 
the value of an optimal solution recursively, instead, defining the value of a general 
solution is enough. The optimal value, as well as its associated solution, is obtained 
automatically by the TLP systems. This new scheme has been implemented in the 
authors' TALS system with very encouraging results. 
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